Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VK_EXT_mesh_shader, version 2 #1125

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

Firestar99
Copy link

@Firestar99 Firestar99 commented Feb 1, 2024

!!! builds on top of PR #1118, which needs to be merged first

Adds support for VK_EXT_mesh_shader, rebased from the abandoned PR #1019 by @BeastLe9enD. Note that I have split the PR in two parts: PR #1118 handles updating to a more recent rspirv version, whereas this PR only handles the additions needed for VK_EXT_mesh_shader support.

(Sorry if the diff currently looks horrid, as it currently shows 2 PRs in one. As soon as the other PR is merged, I'll rebase this one and the diff should be way easier to review on github)

@Firestar99 Firestar99 requested a review from eddyb as a code owner February 1, 2024 14:56
#[spirv_std_macros::gpu_only]
#[doc(alias = "OpEmitMeshTasksEXT")]
#[inline]
pub unsafe fn emit_mesh_tasks_ext(group_count_x: u32, group_count_y: u32, group_count_z: u32) -> ! {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation on OpEmitMeshTasksEXT mentions an optional payload pointer, which does not exist on this function. The compiletests contain examples on mesh and task shaders with payloads. But I'm unsure how rust-gpu handles payloads in general, and if this is the correct way to handle them or not.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved it by adding an explicit emit_mesh_tasks_ext_payload() that takes a payload param simiarly to raytracing.

@Firestar99 Firestar99 force-pushed the actual_mesh_shaders branch 4 times, most recently from 8af2717 to 05e8c8d Compare February 7, 2024 09:47
@Firestar99
Copy link
Author

I've successfully used mesh shaders generated by this branch in a small demo: I had a workgroup size of 1 with each invocation processing a single triangle and was able to render the "lantern" model from glTF-sample-assets. Proper meshlets to be implemented and tested soon.

pub fn main(#[spirv(push_constant)] push: &u32) {
let count = 20 / *push;
unsafe {
emit_mesh_tasks_ext(1, 2, 3);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This causes rust-gpu to emit invalid byte code and I do not know why. Specifically, any possibility of a panic, like the 20 / *push when push is 0, will cause a mispile in any task shader that calls emit_mesh_tasks_ext() at the end (which is required by spec). Interestingly, this does not happen to OpKill in fragment shaders, so likely some misconfiguration on my part?

normalized stderr:
error: error:0:0 - Selection must be structured
         OpBranchConditional %24 %25 %26
  |
  = note: spirv-val failed
  = note: module `$TEST_BUILD_DIR/arch/task_shader_mispile.default`

error: aborting due to previous error

@Firestar99 Firestar99 force-pushed the actual_mesh_shaders branch from 8ede584 to 583f886 Compare June 11, 2024 11:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants